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In this paper we propose an extension of the Rebeca language that can be used to model 
distributed and asynchronous systems with timing constraints. We provide the formal 
semantics of the language using Structural Operational Semantics, and show its expressive- 
ness by means of examples. We developed a tool for automated translation from timed 
Rebeca to the Erlang language, which provides a first implementation of timed Rebeca. 
We can use the tool to set the parameters of timed Rebeca models, which represent the 
environment and component variables, and use McErlang to run multiple simulations for 
different settings. Timed Rebeca restricts the modeller to a pure asynchronous actor-based 
paradigm, where the structure of the model represents the service oriented architecture, 
while the computational model matches the network infrastructure. Simulation is shown 
to be an effective analysis support, specially where model checking faces almost immediate 
state explosion in an asynchronous setting. 



1 Introduction 

This paper presents an extension of the actor-based Rebeca language ||22| that can be used to 
model distributed and asynchronous systems with timing constraints. This extension of Rebeca 
is motivated by the ubiquitous presence of real-time computing systems, whose behaviour 
depends crucially on timing as well as functional requirements. 

A well-established paradigm for modelling the functional behaviour of distributed and 
asynchronous systems is the actor model. This model was originally introduced by Hewitt HQ 
as an agent-based language, and is a mathematical model of concurrent computation that treats 
actors as the universal primitives of concurrent computation [1]. In response to a message that 
it receives, an actor can make local decisions, create more actors, send more messages, and 
determine how to respond to the next message it receives. Actors have encapsulated states 
and behaviour, and are capable of redirecting communication links through the exchange of 
actor identities. Different interpretations, dialects and extensions of actor models have been 
proposed in several domains and are claimed to be the most suitable model of computation for 
the dominating applications, such as multi-core programming and web services 0. 

Reactive Objects Language, Rebeca l|22l , is an operational interpretation of the actor model 
with formal semantics and model-checking tools. Rebeca is designed to bridge the gap between 
formal methods and software engineers. The formal semantics of Rebeca is a solid basis 
for its formal verification. Compositional and modular verification, abstraction, symmetry 
and partial-order reduction have been investigated for verifying Rebeca models. The theory 
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underlying these verification methods is already established and is embodied in verification 
tools lTl4ll2Tll22| . With its simple, message-driven and object-based computational model, Java- 
like syntax, and a set of verification tools, Rebeca is an interesting and easy-to-learn model for 
practitioners. 

Motivation and Contribution. Although actors are attracting more and more attention both 
in academia and industry, little has been done on timed actors and even less on analyzing timed 
actor-based models. In this work we present 

• timed Rebeca by extending Rebeca with time constraints, 

• the formal semantics of timed Rebeca using Structural Operational Semantics (SOS) ||T9|, 

• a tool for mapping timed Rebeca models to Erlang, and 

• experimental results from the simulation of timed Rebeca models using McErlang 0. 

The contribution of this work is offering a pure asynchronous actor-based modelling lan- 
guage with timing primitives and analysis support. Timed Rebeca can be used in a model-driven 
methodology in which the designer builds an abstract model where each component is a reac- 
tive object communicating through non-blocking asynchronous messages. The structure of the 
model can very well represent service oriented architectures, while the computational model 
matches the network infrastructure. Hence the model captures faithfully the behaviour of the 
system in a distributed and asynchronous world. 

Comparison with other timed models. Comparing with the well-established timed mod- 
els, like timed automata |2], TCCS |25j, and real-time Maude [18], timed Rebeca offers an 
actor-based syntax and a built-in actor-based computational model, which restricts the style 
of modelling to an event-based concurrent object-based paradigm. Modelling time-related 
features in computational models has been studied for a long time H3j [2); while we have no 
claims of improving the expressiveness of timed models, we believe that our model is highly 
usable due to its actor-based nature and Java-like syntax. The usability is due to the one to one 
correspondence between the entities of the real world and the objects in the model, and the 
events and actions of the real world and the computational model. Moreover, the syntax of the 
language is familiar for software engineers and practitioners. 

Comparison with other timed actor models. We know of a few other timed actor-based 
modelling languages H20[|T6l l4 | that we will explain in more detail in the related work section. In 
l|20| a central synchronizer acts like a coordinator and enforces the real-time and synchronization 
constraints (called interaction constraints). The language for the coordinated actors is briefly 
proposed in |l6|; however, the main focus is having reusable real-time actors without hardwired 
interaction constraints. The constraints declared within the central synchronizer in this line of 
work can be seen as the required global properties of a timed Rebeca model. We capture the 
architecture and configuration of a system via a timed Rebeca model and then we can check 
whether the global constraints are satisfied. The language primitives that we use to extend 
Rebeca are consistent with the proposal in l!T6ll . The primitives proposed in [4j are different 
from ours; they introduced an await primitive where we keep the asynchronous nature of the 
model. 
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Analysis support. In order to analyze timed Rebeca models, we developed a tool to facilitate 
their simulation. In a parallel project [11], a mapping from timed Rebeca to timed automata is 
developed and UPPAAL [24 J is used for model checking. The asynchronous nature of Rebeca 
models causes state explosion while model checking even for small models. One solution is 
using a modular approach like in tl2| . Here, we selected an alternative solution as a comple- 
mentary tool for analysis. Using our tool we can translate a timed Rebeca model to Erlang (6|, 
set the parameters which represent the environment and component variables, and run McEr- 
lang [7] to simulate the model. The tool allows us to change the settings of different timing 
parameters and rerun the simulation in order to investigate different scenarios, find potential 
bugs and problems, and optimize the model by manipulating the settings. The parameters can 
be timing constraints on the local computations (e.g., deadlines for accomplishing a requested 
service), computation time for providing a service, and frequency of a periodic event. Param- 
eters can also represent network configurations and delays. In our experiments we could find 
timing problems that caused missing a deadline, or an unstable state in the system. 

The formal semantics presented in this paper is the basis for the correct mapping from 
timed Rebeca to Erlang. The detailed mapping, and the tool together with some examples can 
be found at IflQl. 

Our choice to use the actor-based programming language Erlang is also based on the idea 
of covering the whole life cycle of the system in future, and of providing a refinement step for 
implementing the code from our timed Rebeca model. 

2 Related Work 

Different approaches are used in designing formal modelling languages for real-time systems. 
The model of timed automata, introduced by Alur and Dill 0, has established itself as a 
classic formalism for modelling real-time systems. The theory of timed automata is a timed 
extension of automata theory, using clock constraints on both locations and transitions. In many 
other cases the proposed modelling languages for real-time systems are extensions of existing 
languages with real-time concepts — see, for example, TCCS [25 J and Real-time Maude l|T8ll . 

A real-time actor model, RT-synchronizer, is proposed in |20| , where a centralized syn- 
chronizer is responsible for enforcing real-time relations between events. Actors are extended 
with timing assumptions, and the functional behaviours of actors and the timing constraints 
on patterns of actor invocation are separated. The semantics for the timed actor-based lan- 
guage is given in |[T6l . Two positive real- valued constants, called release time and deadline, are 
added to the send statement and are considered as the earliest and latest time when the message 
can be invoked relative to the time that the method executing the send is invoked. In Timed 
Rebeca, we have the constructs after and deadline, which are representing the same concepts, 
respectively, except that they are relative to the time that the message (itself) is sent. So, it more 
directly reflects the computation architecture including the network delays. In our language, 
it is also possible to consider a time delay in the execution of a computation where in |T6| it is 
possible to specify an upper bound on the execution time of a method. While RT-synchronizer 
is an abstraction mechanism for the declarative specification of timing constraints over groups 
of actors, our model allows us to work at a lower level of abstraction. Using timed Rebeca, 
a modeller can easily capture the functional features of a system, together with the timing 
constraints for both computation and network latencies, and analyze the model from various 
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points of view. 

There is also some work on schedulability analysis of actors [17], but this is not applied on 
a real-time actor language. Time constraints are considered separately. Recently there have 
been some studies on schedulability analysis for Rebeca models ||T3| . This work is based on 
mapping Rebeca models to timed automata and using UPPAAL to check the schedulability of 
the resulting models. Deadlines are defined for accomplishing a service and each task spends a 
certain amount of time for execution. In the above-mentioned papers, modelling of time is not 
incorporated in the Rebeca language. 

Creol is a concurrent object-oriented language with an operational semantics written in an 
actor-based style, and supported by a language interpreter in the Maude system. In [5J, Creol is 
extended by adding best-case and worst-case execution time for each statement, and a deadline 
for each method call. In addition, an object is assigned a scheduling strategy to resolve the 
nondeterminism in selecting from the enabled processes. This work is along the same lines as 
the one presented in [13J and the focus is on schedulability analysis, which is carried out in a 
modular way in two steps: first one models an individual object and its behavioural interface 
as timed automata, and then one uses UPPAAL to check the schedulability considering the 
specified execution times and the deadlines. In this work, network delays are not considered, 
and the execution time is weaved together with the statements in a fine-grained way. 

In [4] a timed version of Creol is presented in which the only additional syntax is read- 
only access to the global clock, plus adding a data-type Time together with its accompanying 
operators to the language. Timed behaviour is modelled by manipulating the Time variables 
and via the await statement in the language. 

3 Timed Rebeca 

A Rebeca model consists of a set of reactive classes and the main program in which we declare 
reactive objects, or rebecs, as instances of reactive classes. A reactive class has an argument of type 
integer, which denotes the length of its message queue. The body of the reactive class includes 
the declaration for its known rebecs, variables, and methods (also called message servers). Each 
method body consists of the declaration of local variables and a sequence of statements, which 
can be assignments, if statements, rebec creation (using the keyword new), and method calls. 
Method calls are sending asynchronous messages to other rebecs (or to self) to invoke the 
corresponding message server (method). Message passing is fair, and messages addressed to a 
rebec are stored in its message queue. The computation takes place by taking the message from 
the front of the message queue and executing the corresponding message server |22l . 

Timing features in an asynchronous and distributed setting. To decide on the timing prim- 
itives to be added to the Rebeca syntax, we first considered the different timing features that 
a modeller might need to address in a message-based, asynchronous and distributed setting. 
These features (like the computation time, or periodic events) can be common in any setting. 

1. Computation time: the time needed for a computation to take place. 

2. Message delivery time: the time needed for a message to travel between two objects, that 
depends on the network delay (and possibly other parameters). 
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3. Message expiration: the time within which a message is still valid. The message can be 
a request or a reply to a request (a request being served). 

4. Periods of occurrences of events: the time periods for periodic events. 

We introduce an extension of Rebeca with real-time primitives to be able to address the 
above-mentioned timing features. In timed Rebeca model, each rebec has its own local clock, 
which can be considered as synchronized distributed clocks^] Methods are still executed 
atomically but we can model passing of time while executing a method. Instead of a message 
queue for each rebec, we have a bag containing the messages that are sent. The timing primitives 
that are added to the syntax of Rebeca are delay, now, deadline and after. Figure [T] shows the 
grammar for Timed Rebeca. The delay statement models the passing of time for a rebec during 
execution of a method (computation time), and now returns the local time of the rebec. The 
keywords after and deadline can only be used in conjunction with a method call. Each rebec 
knows about its local time and can put deadline on the messages that are sent declaring that 
the message will not be valid after the deadline (modelling the message expiration). The after 
primitive, attached to a message, can be used to declare a constraint on the earliest time at 
which the message can be served (taken from the message bag by the receiver rebec). The 
modeller may use these constraints for various purposes, such as modelling the network delay 
or modelling a periodic event. 

The messages that are sent are put in the message bag together with their time tag and 
deadline tag. The scheduler decides which message is to be executed next based on the time 
tags of the messages. The time tag of a message is the value of now when the message was sent, 
with the value of the argument of the after added to it when the message is augmented with an 
after. The intuition is that a message cannot be taken (served) before the time that the time tag 
determines. 

The progress of time is modeled locally by the delay statement. Each delay statement within 
a method body increases the value of the local time (variable now) of the respective rebec by 
the amount of its argument. When we reach a call statement (sending a message), we put that 
message in the message bag augmented with a time tag. The local time of a rebec can also be 
increased when we take a message from the bag to execute the corresponding method. 

The scheduler takes a message from the message bag, executes the corresponding message 
server atomically, and then takes another message. Every time the scheduler takes a message for 
execution, it chooses a message with the least time tag. Before the execution of the corresponding 
method starts, the local time (now) of the receiver rebec is set to the maximum value between its 
current time and the time tag of the message. The current local time of each rebec is the value 
of now. This value is frozen when the method execution ends until the next method of the same 
rebec is taken for execution. 

The arguments of after and delay are relative values, but when the corresponding messages 
are put in the message bag their tags are absolute values, which are computed by adding the 
relative values of the arguments to the value of the variable now of the sender rebec (where 
the messages are sent). To summarize, Timed Rebeca extends Rebeca with the following four 
constructs. 

• Delay: delay(t), where tisa positive natural number, will increase the value of the local 
clock of the respective rebec by the amount t. 

1 In this paper we do not address the problem of distributed clock synchronization; several options and protocols 
for establishing clock synchronization in a distributed system are discussed in the literature, including ]23[. 



6 Modelling and Simulation of Asynchronous Real-Time Systems using Timed Rebeca 



Model : 


:= EnvVar* Class* Main EnvVar ::= env T {v) + ; 


Main : 


:= main { InstanceDcl* } InstanceDcl ::= C r((r)*) : ((c)*); 


Class : 


:= reactiveclass C { KnownRebecs Vars MsgSrv* } 


KnownRebecs : 


:= knownrebecs { VarDcl* } Vars ::= statevars { VarDcl* } VarDcl ::= T (v) + ; 


MsgSrv : 


:= msgsrv M((T z?)*) { Sfraf* } 


Stmt : 


:= v = e; \ r = new C((e)*); \ Call; | if (e) MSt [else MSt] | delay(f); | now(); 


Call: 


:= r.M((e)*) [after(f)] [deadline(f)] 


MSt: 


:= { Stmt* } | Stmt 



Figure 1: Abstract syntax of Timed Rebeca. Angle brackets (...) are used as meta parenthesis, 
superscript + for repetition more than once, superscript * for repetition zero or more times, 
whereas using (...) with repetition denotes a comma separated list. Brackets [...] show being 
optional. Identifiers C, T, M, v, c, and r denote class, type, method, variable, constant, and rebec 
names, respectively; and e denotes an (arithmetic, boolean or nondetermistic choice) expression. 



• Now: now() returns the time of the local clock of the rebec from which it is called. 

• Deadline: r.m() deadline(t) , where r denotes a rebec name, m denotes a method name of r 
and t is a natural number, means that the message m is sent to the rebec r and is put in the 
message bag. After t units of time the message is not valid any more and is purged from 
the bag. Deadlines are used to model message expirations (timeouts). 

• After: r.m() after(t), where r denotes a rebec name, m denotes a method name of r and 
t is a natural number, means that the message m is sent to the rebec r and is put in the 
message bag. The message cannot be taken from the bag before t time units have passed. 
After statements can be used to model network delays in delivering a message to the 
destination, and also periodic events. 

Ticket Service Example We use a ticket service as a running example throughout the article. 
Listing [I] shows this example written in Timed Rebeca. The ticket service model consists 
of two reactive classes: Agent and Tickets ervice. Two rebecs, tsl and ts2, are instantiated 
from the reactive class Tickets ervice, and one rebec a is instantiated from the reactive class 
Agent. The agent a is initialized by sending a message findTicket to itself in which a message 
requestTicket is sent to the ticket service tsl or tsl based on the parameter passed to findTicket. 
The deadline for the message requestTicket to be served is requestDeadline time units. Then, 
after checklssuedPeriod time units the agent will check if it has received a reply to its request by 
sending a checkTicket message to itself, modelling a periodic event. There is no receive statement 
in Rebeca, and all the computation is modeled via asynchronous message passing, so, we need 
a periodic check. The attemptCount variable helps the agent to keep track of the ticket service 
rebec that the request is sent to. The token variable allows the agent to keep track of which 
incoming ticketlssued message is a reply to a valid request. When any of the ticket service rebecs 
receives the requestTicket message, it will issue the ticket after serviceTimel or serviceTimel time 
units, which is modelled by sending ticketlssued to the agent with the token as parameter. The 
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expression 1 (serviceTimel, serviceTimel) denotes a nondeterministic choice between serviceTimel 
and serviceTimel in the assignment statement. Depending on the chosen value, the ticket service 
may or may not be on time for its reply. 



env int requestDeadline , 
serviceTime2 ; 



checklssuedPeriod, retryRequestPeriod, newRequestPeriod, serviceTimel, 



check 1st ticket service 



reactiveclass Agent { 
knownrebecs { TicketService tslj TicketService ts2; } 
statevars { int attemptCount ; boolean ticketlssued; int token; } 
msgsrv initialO { self . findTicket(tsl) ; } // initialize system, 
msgsrv findTicket (TicketService ts) { 
attemptCount += 1 ; token += 1 ; 

ts.requestTicket (token) deadline (requestDeadline) ; // send request to the TicketService 
self . checkTicketO after(checklssuedPeriod) ; // check if the request is replied 

} 

msgsrv ticketlssued(int tok) { if (token == tok) { ticketlssued = true; } } 
msgsrv checkTicketO { 

if ('ticketlssued && attemptCount == 1) { 



self .findTicket (ts2) ; 

else if (! ticketlssued && attemptCount 

self .retry () after(retryRequestPeriod) ; 

else if (ticketlssued) { 

ticketlssued = false; 

self .retry () after(newRequestPeriod) ; 



} 

msgsrv retryO { 
attemptCount = 

} 



0; self .findTicket(tsl) ; 



// no ticket from 1st service, 
// try the second TicketService 
2) { // no ticket from 2nd service, 

// restart from the first TicketService 
// the second TicketService replied, 

// new request by a customer 



// restart from the first TicketService 



} 



reactiveclass TicketService { 
knownrebecs { Agent a; } 
msgsrv initialO { } 
msgsrv requestTicket(int token) { 

int wait = ? (serviceTimel , serviceTime2) ; 

delay(wait) ; 

a.ticketlssued(token) ; 



// the ticket service sends the reply 
// after a non-determinstic delay of 
// either serviceTimel or serviceTime2 



} 



} 



main { 

Agent a(tsl, ts2) : () ; 
TicketService tsl(a):(); 
TicketService ts2(a):(); 

} 



// instantiate agent, with two known rebecs 
// instantiate 1st and 2nd ticket services, 
// the agent as their known rebecs 



with 



Listing 1: A Timed Rebeca model of the ticket service example 



3.1 Structural Operational Semantics for Timed Rebeca 

In this section we provide an SOS semantics for Timed Rebeca in the style of Plotkin [19J. The 
behaviour of Timed Rebeca programs is described by means of the transition relation — > that 
describes the evolution of the system. 

The states of the system are pairs (Env,B), where Env is a finite set of environments and B 
is a bag of messages. For each rebec A of the program there is an environment a a contained 
in Env, that is a function that maps variables to their values. The environment a a represents 
the private store of the rebec A. Besides the user-defined variables, environments also contain 
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the value for the special variables self, the name of the rebec, now, the current time, and sender, 
which keeps track of the rebec that invoked the method that is currently being executed. The 
environment a a also maps every method name of A to its body. 

The bag contains an unordered collection of messages. Each message is a tuple of the 
form (Aj,m(v),Aj,TT,DL). Intuitively such a tuple says that at time TT the sender Aj sent the 
message to the rebec A, asking it to execute its method m with actual parameters v. Moreover 
this message expires at time DL. 

The system transition relation — > is defined by the rule scheduler: 

((^.(m), cr^. [now = max(TT,aA.(nozu)), [arg - v], sender = Aj], Env, B)—>(a' A , Env' ,B') 

(scheduler) '■ C 

({o A ,}<JEnv,{(Ai,m(v),Aj,TT,DL)}UB)^ {{a' A )UEnv', B') 

where the condition C is defined as follows: a a, is not contained in Env, and (Ai,m(v),Aj,TT,DL) g. 
B, and OAj(now) < DL, and TT < min(B). The scheduler rule allows the system to progress by 
picking up messages from the bag and executing the corresponding methods. The third side 
condition of the rule, namely aAfinow) < DL, checks whether the selected message carries an 
expired deadline, in which case the condition is not satisfied and the message cannot be picked. 
The last side condition is the predicate TT < min(B), which shows that the time tag TT of the 
selected message has been the smallest time tag of all the messages for all the rebecs A,- in the 
bag B. The premise executes the method m, as described by the transition relation A, which 
will be defined below. The method body is looked up in the environment of A, and is executed 
in the environment of A, modified as follows: (1) The variable sender is set to the sender of 
the message. (2) In executing the method m, the formal parameters org are set to the values of 
the actual parameters v. Methods of arity n are supposed to have argi,arg2,...,arg n as formal 
parameters. This is without loss of generality since such a change of variable names can be 
performed in a pre-processing step for any program. (3) The variable now is set to the maximum 
between the current time of the rebec and the time tag of the selected message. 

The execution of the methods of rebec A, may change the private store of the rebec A„ the 
bag B by adding messages to it and the list of environments by creating new rebecs through new 
statements. Once a method is executed to completion, the resulting bag and list of environments 
are used to continue the progress of the whole system. 

The transition relation — > describes the execution of methods in the style of natural seman- 
tics JI51 . (See Figure [2] for selected rules. The full set of rules may be found in Appendix [A]) 
Since in this kind of semantics the whole computation of a method is performed in a single 
step, this choice perfectly reflects the atomic execution of methods underlying the semantics of 
the Rebeca language. The general form of this type of transition is (S,o,Env,B) A (a' ,Env' ,B'). 
A single step of — > consumes all the code S and provides the value resulting from its execution. 
Carrying the bag B is important because new messages may be added to it during the execution 
of a statement S. Also Env is required because new statements create new rebecs and may 
therefore add new environments to it. In the semantics, the local environment a is separated 
from the environment list Env for the sake of clarity. The result of the execution of the method 
thus amounts to the modified private store a' , the new list of environments Env' and the new 
bag B' . 

The rules for assignment, conditional statement and sequential composition are standard. 
The rules for the timing primitives deserve some explanation. 
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(tnsg) (vamame. m(v) after(d) deadline(DL),a,Env,B) 

—>(o,Env,{ (a(vamame),m(eva](v, a)), a(self), a{now) + d, a(now) + DL) ) U B) 
(delay) (delay(d),a,Env,B) ^> (a[now = a(now) + d],Env,B) 
(create) (vamame = new 0(v),a,Env,B) 

—>(o[varname = A], {onflow = a(now), self = A]}UEnv / {(A / initial(eval(v / o)) / o(self),a(now),+oo)}uB) 



Figure 2: Selected Method-Execution Transition Rules. In rule create, the rebec name A should 
not appear in the range of the environment a. The function eval evaluates expressions in a given 
environment in the expected way. In each rule, we assume that a is not contained in Env. 

• Rule msg describes the effect of method invocation statements. For the sake of brevity, 
we limit ourselves to presenting the rule for method invocation statements that involve 
both the after and deadline keywords. The semantics of instances of that statement without 
those keywords can be handled as special cases of that rule by setting the argument of 
after to zero and that of deadline to +00, meaning that the message never expires. Method 
invocation statements put a new message in the bag, taking care of properly setting its 
fields. In particular the time tag for the message is the current local time, which is the 
value of the variable now, plus the number d that is the parameter of the after keyword. 

• Delay statements change the private variable now for the considered rebec. 

Finally, the creation of new rebecs is handled by the rule create. A fresh name A is used to 
identify the newly created rebec and is assigned to vamame. A new environment a a is added to 
the list of environments. At creation time, a a is set to have its method names associated to their 
code. A message is put in the bag in order to execute the initial method of the newly created 
rebec. 

4 Mapping from Timed Rebeca to Erlang 

In this section, we present a translation from the fragment of Timed Rebeca without rebec 
creation to Erlang (for an extended explanation and a more formal description see [10]). The 
motivation for translating Timed Rebeca models to Erlang code is to be able to use McErlang Q 
to run experiments on the models. This translation also yields a first implementation of Timed 
Rebeca. 

McErlang is a model-checking tool written in Erlang to verify distributed programs written 
in Erlang. It supports Erlang datatypes, process communication, fault detection and fault 
tolerance and the Open Telecom Platform (OTP) library, which is used by most Erlang programs. 
The verification methods range from complete state-based exploration to simulation, with 
specifications written as LTL formulae or hand-coded runtime monitors. This paper focuses 
on simulation since model checking with real-time semantics is not yet offered by McErlang. 
Note, however, that our translation opens the possibility of model checking (untimed) Rebeca 
models using McErlang, which is not the subject of this paper. 
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receive 






Patternl when 


Guard 1 


-> Exprl; 


Pattern2 when 


Guard2 


-> Expr2 ; 


after 






Time -> Expr 






end 







Listing 2: Syntax of a receive with timeout. 



Erlang Primer Erlang is a dynamically-typed general-purpose programming language, which 
was designed for the implementation of distributed, real-time and fault-tolerant applications. 
Originally, Erlang was mostly used for telephony applications such as switches. Its concurrency 
model is based on the actor model. 

Erlang has few concurrency and timing primitives: 

• Pid = spawn(Fun) creates a new process that evaluates the given function Fun in parallel 
with the process that invoked spawn. 

• Pid ! Msg sends the given message Msg to the process with the identifier Pid. 

• receive . . . end receives a message that has been sent to a process; message discrimination 
is based on pattern matching. 

• after is used in conjunction with a receive and is followed by a timeout block as shown in 
Listing |2j after the specified time (deadline for receiving the required pattern) the process 
executes the timeout block 

• erlang :now() returns the current time of the process 

When a process reaches a receive expression it looks in the queue and takes a message that 
matches the pattern if the corresponding guard is true. A guard is a boolean expression, which 
can include the variables of the same process. The process looks in the queue each time a 
message arrives until the timeout occurs. 

Mapping The abstract syntax for a fragment of Erlang that is required to present the translation 
is shown in Figure [3] Table [I] offers an overview of how a construct in one language relates to 
one in the other. We discuss the general principles behind our translation in more detail below. 

Reactive classes are translated into three functions, each representing a possible behaviour 
of an Erlang process: 1) the process waits to get references to known rebecs, 2) the process 
reads the initial message from the queue and executes it, 3) the process reads messages from 
the queue and executes them. Once processes reach the last function they enter a loop. Erlang 
pseudocode for the reactive class TicketService in the Rebeca model in Listing [I] is shown in 
Listing |3j 

A message server is translated into a match expression (see Figure |3|, which is used inside 
receive . . . end. In Listing [3j requestTicket is the pattern that is matched on, and the body of the 
message server is mapped to the corresponding expression. 

Message send is implemented depending on whether after is used. If there is no after, 
the message is sent like a regular message using the ! operator, as shown on line 4 in Listing 
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Program 


::= Function* Function ::= v(Pattern*) — > e 




Expr 


::= e\ op e e^ \ e{(e)*) \ e\ ! e2 I e\ , \ Pattern - e | case 


e of Match end | receive Match end 




receive Match after Time — > e end| if (Mafc/j)*end 


| BasicValue \ v \ {(e)*} \ [(e)*] 


Match 


::= Pattern when Guard — > e 




Pattern 


::= i? | BasicValue \ {(Pattern)*} \ [(Pattern)*] Time ::= 


int 


Value 


::= BasicValue \ {(Value)*} \ [(Value)*] BasicValue ::= 


atom | number | pid | fid 


Guard 


::= gl op g g 2 | BasicValue \ v \ g((g)*) \ {(g)*} \ [(g)*] 





Figure 3: Abstract syntax of a relevant subset of Erlang. Angle brackets (...) are used as meta 
parenthesis, superscript + for repetition more than once, superscript * for repetition zero or 
more times, whereas using (...) with repetition denotes a comma separated list. Identifiers v, p 
and g denote variable names, patterns and guards, respectively, and e denotes an expression. 
Note that {} and [] are parts of the syntax of Erlang representing tuples and lists, respectively. 



Timed Rebeca 



Erlang 



Model 
Reactive classes 
Known rebecs 
State variables 
Message server 
Local variables 
Message send 
Message send w/after 



Message send w/deadline 
Delay statement 
Now expression 
Assignment 
If statement 
Nondeterministic selection 



A set of processes 

A process whose behaviour consists of three functions 

Record of variables 

Record of variables 

A match in a receive expression 

Record of variables 

Message send expression 

Message send expression in the timeout block of a receive 

with an empty pattern, the timeout block is always executed, 

sending the message after the specified time 

Message send expression with the deadline as parameter 

Empty receive with a timeout 

System time 

Record update 

If expression 

Random selection in Erlang 



Table 1: Structure of the mapping from Timed Rebeca to Erlang. 
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ticketServiceO -> 
receive 

% wait for a message with a set of known rebecs 
{Agent} -> 
% proceed to the next behaviour 

ticketService(#ticketService_knownrebecs{agent=Agent}) 
end. 

ticketService(KnownRebecs) -> 
receive 

% wait for the 'initial' message 
initial -> 

% process message 'initial' and proceed to the next behaviour 
ticketService(KnownRebecs , #ticketService_statevars{}) 
end. 

ticketService(KnownRebecs, StateVars) -> 
receive 

% wait for each message servers 
requestTicket -> 

% process message 'requestTicket ' and loop 

ticketService(KnownRebecs , StateVars) 
end. 

Listing 3: Pseudo Erlang code capturing the behaviour of the ticketService process. 



Sender = self () , 
spawn(fun() -> 

receive after 15 -> 
TicketService ! {{Sender, now() , inf}, requestTicket} 

end 
end) 

Listing 4: Example of a message send after 15 time units in Erlang. 



[4] However, if the keyword after is present a new process is spawned which sleeps for the 
specified amount of time before sending the message as described before. Setting a deadline 
for the delivery of a message is possible by changing the value inf, which denotes no deadline 
(as shown on line 3 in Listing E), to an absolute point in time. Messages are tagged with the 
time at which they were sent. For the simulation we use the system clock to find out the current 
time by calling the Erlang function now(). 

Moreover, since message servers can reply to the sender of the message, we need to take 
care of setting the sender as part of the message as seen on line 4 in Listing |4j 

As there is no pattern to match with, the delay statement is implemented as a receive 
consisting of just a timeout that makes the process wait for a certain amount of time. For 
example, delay(10) is translated to receive after 10 ->ok end. 

The deadline of each message is checked right before the body of the message server is 
executed. The current time is compared with the deadline of the message to see if the deadline 
has expired and, if so, the message is purged. 
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Request 
deadline 


Check issued 
period 


Retry request 
period 


New request 
period 


Service 
time 1 


Service 
time 2 


Result 


2 


1 


1 


1 


3,4 


7 


Not issued 


2 


2 


1 


1 


4 


7 


Not issued 


2 


2 


1 


1 


3 


7 


Ticket issued 



Table 2: Experimental simulation results for ticket service. 



5 Simulation of Timed Rebeca Using McErlang 

In this section, we present experimental results for two case studies. The first case study is the 
ticket service model displayed in Listing [T] and the second is a model of a sensor network. In 
each case we run a simulation for ten times, and for each case for 30 minutes or until a runtime 
monitor fails, which means that an erroneous state has been reached. The simulations are run 
in a setting in which a time unit is 1000 ms. The experiment platform is Macbook 2.0GHz Intel 
Core 2 Duo - Aluminum 4GB memory Mac OS X, 10.6.6, and Erlang R13B04. 

Ticket Service The ticket service model is described in Section [3] For each simulation, we 
change one of the following parameters: the amount of time that is allowed to pass before a 
request is processed, the time that passes before agent checks if he has been issued a ticket, 
the amount of time that passes before agent tries the next ticket service if he did not receive a 
ticket, the amount of time that passes before agent restarts the ticket requests in case neither 
ticket service issued a ticket and two different service times, which are non-deterministically 
chosen as delay time in a ticket service and model the processing time for a request. Table [5] 
shows different settings of those parameters for which the ticket services never issue a ticket 
to the agent because of tight deadlines, as well as settings for which a ticket is issued during a 
simulation of the model. 

Sensor Network We model a simple sensor network using Timed Rebeca. (See Listing [5] in 
Appendix |B] for the complete description of the model.) A distributed sensor network is set 
up to monitor levels of toxic gasses. The sensor rebecs (sensor® and sensorl), announce the 
measured value to the admin node (admin rebec) in the network. If the admin node receives 
reports of dangerous gas levels, it immediately notifies the scientist (scientist rebec) on the 
scene about it. If the scientist does not acknowledge the notification within a given time frame, 
the admin node sends a request to the rescue team (rescue rebec) to look for the scientist. The 
rescue team has a limited amount of time units to reach the scientist and save him. 

The rebecs sensor® and sensor 1 will periodically read the gas-level measurement, modelled 
as a non-deterministic selection between GAS_L0W and GAS_HIGH, and send their values to admin. 
The admin continually checks, and acts upon, the sensor values it has received. When the admin 
node receives a report of a reading that is life threatening for the scientist (GAS_HIGH), it 
notifies him and waits for a limited amount of time units for an acknowledgement. The rescue 
rebec represents a rescue team that is sent off, should the scientist not acknowledge the 
message from the admin in time. We model the response speed of the rescue team with a 
non-deterministic delay of or 1 time units. The admin keeps track of the deadlines for the 
scientist and the rescue team as follows: 
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Network 


Admin 


Sensor 


Sensor 1 


Scientist 


Rescue 


Result 


delay 


period 


period 


period 


deadline 


deadline 


1 


4 


2 


3 


2 


3 


Mission failed 


1 


4 


2 


3 


2 


4 


Mission success 


2 


1 


1 


1 


4 


5,6,7 


Mission failed 


2 


4 


1 


1 


4 


7 


Mission success 



Table 3: Experimental simulation results for sensor network. 



• the scientist must acknowledge that he is aware of a dangerous gas-level reading before 
scientistDeadline time units have passed; 

• the rescue team must have reached the scientist within rescueDeadline time units. 

Otherwise we consider the mission failed. 

The model can be parameterized over the values of network delay, admin sensor-read 
period, sensor© read period, sensor 1 read period, scientist reply deadline and rescue-team 
reply deadline, as shown in Table |5j In that table, we can see two different cases in which we 
go from mission failure to mission success between simulations. In the first scenario, we go 
from mission failure to success as we increase the rescue deadline, as expected. In the second 
scenario, we changed the parameters to model a faster sensor update and we observed mission 
failure. In this scenario, increasing the rescue deadline further (from 5 to 7) is insufficient. Upon 
closer inspection, we observe that our model fails to cope with the rapid sensor updates and 
admin responses because it enters an unstable state. The admin node initiates a new rescue 
mission while another is still ongoing, eventually resulting in mission failure. This reflects a 
design flaw in the model for frequent updates that can be solved by keeping track of an ongoing 
rescue mission in the model. Alternatively, increasing the value of admin sensor-read period 
above half the rescue deadline eliminates the flaw and the simulation is successful again. 

6 Future Work 

The work reported in this paper paves the way to several interesting avenues for future work. 
In particular, we have already started modelling larger real-world case studies and analyzing 
them using our tool. We plan to explore different approaches for model checking Timed Rebeca 
models. It is worth noting that the translation from Timed Rebeca to Erlang immediately 
opens the possibility of model checking untimed Rebeca models using McErlang. This adds 
yet another component to the verification toolbox for Rebeca, whose applicability needs to be 
analyzed via a series of benchmark examples. As mentioned in the paper, McErlang supports 
the notion of time only for simulation and not in model checking, and therefore cannot be used 
as is for model checking Timed Rebeca models. We plan to explore different ways in which 
McErlang can be used for model checking Timed Rebeca. One possible solution is to store the 
local time of each process and write a custom-made scheduler in McErlang that simulates the 
way the Timed Rebeca scheduler operates. The formal semantics for Timed Rebeca presented 
in this paper is also used in another parallel line of work [11]. The aim of that study is to map 
Timed Rebeca to timed automata |2] in order to use UPPAAL ||24| for model checking Timed 
Rebeca models. The translation from Timed Rebeca to timed automata will be integrated in our 
tool suite. We are also working on a translation of Timed Rebeca into (Real-time) Maude. This 
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alternative translation would allow designers to use the analysis tools supported by Maude 
in the verification and validation of Timed Rebeca models. Our long-term goal is to have a 
tool suite for modelling, executing, simulating, and model checking asynchronous object-based 
systems using Timed Rebeca. 

Acknowledgements The work on this paper has been partially supported by the projects 
"New Developments in Operational Semantics" (nr. 080039021), "Meta-theory of Algebraic 
Process Theories" (nr. 100014021) and "Timed Asynchronous Reactive Objects in Distributed 
Systems: TARO" (nr. 110020021) of the Icelandic Research Fund. 

References 

[1] G. Agha (1990): Actors: A Model of Concurrent Computation in Distributed Systems. MIT Press, 
Cambridge, MA, USA. 

[2] R. Alur & D Dill (1994): A Theory of Timed Automata. Theoretical Computer Science 126, pp. 183-235. 
doi 10.1016/0304-3975(94)90010-8 

[3] Henry Givens Baker (1978): Actor Systems for Real-Time Computation. Technical Report, MIT. 

[4] Joakim Bjork, Einar Broch lohnsen, Olaf Owe & Rudolf Schlatte (2010): Lightweight Time Modeling 
in Timed Creol. In: RTRTS, pp. 67-81. doi jl0.4204/EPTCS.36.4| 

[5] Franks, de Boer, Tom Chothia & Mohammad Mahdi Jaghoori (2009): Modular Schedulability Analysis 
of Concurrent Objects in Creol. In: FSEN, pp. 212-227. doi |l0.1007/978-3-642-11623-0_12| 

[6] Erlang: Erlang Programming Language Homepage. Http://www.erlang.org. 

[7] Lars-Ake Fredlund & Hans Svensson (2007): McErlang: a model checker for a distributed functional 
programming language. In: ICFP, pp. 125-136. doi jl0.1145/1291151.1291171| 

[8] C. Hewitt (1972): Description and Theoretical Analysis (Using Schemata) of PLANNER: A Language for 
Proving Theorems and Manipulating Models in a Robot. MIT Artificial Intelligence Technical Report 
258, Department of Computer Science, MIT. 

[9] Carl Hewitt (2007): What is Commitment? Physical, Organizational, and Social (Revised). In: Proceed- 
ings of Coordination, Organizations, Institutions, and Norms in Agent Systems II, Lecture Notes in 
Computer Science, Springer, pp. 293-307. doi |10.1007/978-3-540-74459-7_19| 

[10] ICEROSE: ICEROSE Homepage. Http://en.ru.is/icerose/applying-formal-methods/projects/TARO. 

[11] Mohammad Javad Izadi (2010): An Actor-based Model for Modeling and Verification of Real-Time Systems 
- Master Thesis, University of Tehran, Iran. 

[12] M. M. Jaghoori, FS. de Boer, T. Chothia & M. Sirjani (2007): Task scheduling in Rebeca. In: Proc. 
Nordic Workshop on Programming Theory (NWPT'07). Extended abstract. 

[13] M. M. Jaghoori, FS. de Boer, T. Chothia & M. Sirjani (2009): Schedulability of Asynchronous Real-Time 
Concurrent Objects. Logic and Algebraic Programming 78(5), pp. 402^16. A preliminary version 
appeared in NWPT/FLACOS 2007 as an extended abstract. doi |10.1016/j.jlap.2009.02l)0"9"j 

[14] Mohammad Mahdi Jaghoori, Marjan Sirjani, Mohammad Reza Mousavi, Ehsan Khamespanah & 
Ali Movaghar (2009): Symmetry and Partial Order Reduction Techniques in Model Checking Rebeca. Acta 
InformaticaeA7(l), pp. 33-66. doi |TaT007/s00236-009-0111-x| 

[15] Gilles Kahn (1987): Natural Semantics. In Franz-Josef Brandenburg, Guy Vidal-Naquet & Martin 
Wirsing, editors: STACS 87, 4th Annual Symposium on Theoretical Aspects of Computer Science, 
Passau, Germany, February 19-21, 1987, Proceedings, Lecture Notes in Computer Science 247, 
Springer-Verlag, pp. 22-39. doi: 10.1007/BFb0039592 



16 



Modelling and Simulation of Asynchronous Real-Time Systems using Timed Rebeca 



[16] Brian Nielsen & Gul Agha: Semantics for an actor-based real-time language. In: Proceedings of The 
Fourth International Workshop on Parallel and Distributed Real-Time Systems (WPDRS'96), IEEE 
Computer Society Press, Los Alamitos, CA, USA, 1996. 

[17] Libera Nigra & Francesco Pupo (2001): Schedulability Analysis of Real Time Actor Systems Using 
Coloured Petri Nets. In: Proc. Concurrent Object-Oriented Programming and Petri Nets, pp. 493- 
513. doi |T0T007/3-540-45397-0^1[ 

[18] Peter Csaba Olveczky & Jose Meseguer (2002): Specification of real-time and hybrid systems in rewriting 



logic. Theor. Comput. Sci. 285(2), pp. 359-405. doi 10.1016/S0304-3975(01)00363-2 

[19] G. D. Plotkin (1981): A Structural Approach to Operational Semantics. Technical Report DAIMI FN-19, 

Computer Science Department, Aarhus University, Aarhus, Denmark. 
[20] Shangping Ren & Gul Agha (1995): RT-synchronizer: Language Support for Real-Time Specifications in 

Distributed Systems. In: Workshop on Languages, Compilers and Tools for Real-Time Systems, pp. 

50-59. doi |10.1145/216636.216656[ 

[21] M. Sirjani, A. Movaghar, A. Shali & ES. de Boer (2005): Model Checking, Automated Abstraction, 
and Compositional Verification of Rebeca Models. Journal of Universal Computer Science 11(6), pp. 
1054-1082. 

[22] M. Sirjani, A. Movaghar, A. Shali & ES. de Boer (Dec. 2004): Modeling and Verification of Reactive 
Systems using Rebeca. Fundamenta Informatica 63(4), pp. 385-410. 

[23] Andrew S. Tanenbaum & Maarten van Steen (2007): Distributed systems - principles and paradigms (2. 
ed.). Pearson Education. 

[24] UPPAAL: UPPAAL Homepage. Http://uppaal.com. 

[25] Wang Yi (1991): CCS + time = an interleaved model for real time systems. In: Proceedings of ICALP 



1991, Lecture Notes in Computer Science 510, Springer- Verlag, pp. 217-228. doi: 10.1007/3-540- 
5423323361 



L. Aceto at al. 

A Method-Execution Transition Rules 



17 



(fUSg) (vamame.m(v) after(d) deadline(DL),o,Env,B) 

—>(o,Env,( (aiparname), m(eval(v, a)), a(self), a(now) + d, a(now) + DL)j U B) 

(delay) (delay(d),a,Env,B) —> (a[now = a(now) + d],Env,B) 

(assign) (x = e,a,Env,B)^>(a\x = eval(e,a)],Env,B) 

(create) (varname = new 0(v),a,Env,B) 

—> (o[varname = A],io A [now = a(now), self = A]}UEnv,[(A,initial(eval(v,a)),a(self)),a(nozv),+oo)]uB) 

eval(e,a) = true (Si,a,Env,B) —>(o',Env',B') 

(condi) 

(;'/ (e) then Si else S2,0,Env,B)—>(o',Env',B') 
eval(e,a) - false {S^,a,Env,B) —> (o' ,Env' ,B') 

(condz) 

(if (e) then S\ else S2, o,Env,B)—>(o',Env',B') 

{Sx,o,Env,B)^(p' ,Env' ,B'), (S 2 ,o',Env',B')^>(o",Env",B") 

(seq) 

(Si;S 2 ,ff, Env, B) ±> (a" ,Env" ,B") 



Figure 4: The Method-Execution Transitions Rules. In rule create, the rebec name A should not 
appear in the range of the environment a. The function eval evaluates expressions in a given 
environment in the expected way. In each rule, we assume that a is not contained in Env. 



B Rebeca Model for the Sensor Network 



env int netDelay; 
env int adminCheckDelay ; 
env int sensor0period; 
env int sensor lperiod; 
env int scientistDeadline; 
env int rescueDeadline; 

reactiveclass Sensor { 
knownrebecs { 

Admin admin; 

} 

statevars { 

int period; 

} 
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msgsrv initial (int myPeriod) { 
period = myPeriod; 
self .doReportO ; 

} 

msgsrv doReportO { 
int value; 

value = ?(2, 4); // 2=safe gas levels, 4=danger gas levels 
admin . report (value) after (netDelay) ; 
self .doReportO after (period) ; 

} 

} 

reactiveclass Scientist { 
knownrebecs { 

Admin admin; 

} 

msgsrv initial () {} 

msgsrv abortPlanO { 

admin. ack() after(netDelay) ; 

} 

} 

reactiveclass Rescue { 
knownrebecs { 

Admin admin; 

} 

msgsrv initial () {} 

msgsrv go() { 

int msgDeadline = now() + (rescueDeadline-netDelay) ; 

int excessiveDelay = ?(8, 1); // unexpected obstacle might occur during rescue 
delay(excessiveDelay) ; 

admin. rescueReach() after(netDelay) deadline (msgDeadline) ; 

} 

} 

reactiveclass Admin { 
knownrebecs { 

Sensor sensorS; 
Sensor sensor 1; 
Scientist scientist; 
Rescue rescue; 

} 

statevars { 

boolean reportedQ; 
boolean reportedl ; 
int sensorValueS; 
int sensorValuel ; 
boolean sensorFailure; 
boolean scientistAck; 
boolean scientistReached; 
boolean scientistDead; 

} 

msgsrv initial () { 

self . checkSensors() ; 

} 



msgsrv report (int value) { 
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} 



if (sender == sensor®) { 

reportedS = true; 

sensorValueS = value ; 
} else { 

reportedl = true; 

sensorValuel = value; 

} 



} 



msgsrv rescueReachO { 

scientistReached = true; 

} 

msgsrv checkSensorsO { 

if (reported®) reportedS = false; 
else sensorFailure = true; 

if (reportedl) reportedl = false; 
else sensorFailure = true; 

boolean danger = false; 

if (sensorValueS > 3) danger = true; 

if (sensorValuel > 3) danger = true; 

if (danger) { 

scientist . abortPlanO after (netDelay) ; 

self .checkScientistAck() after(scientistDeadline) ; // deadline for the scientist to answer 

} 



self . checkSensorsO after(adminCheckDelay) ; 



} 



msgsrv checkRescueO { 

if (! scientistReached) { 

scientistDead = true; // scientist is dead 
} else { 

scientistReached = false; 

} 

} 

msgsrv ack() { 

scientistAck = true; 

} 

msgsrv checkScientistAckO { 
if (! scientistAck) { 

rescue. go() after(netDelay) ; 

self .checkRescueO after(rescueDeadline) ; 

} 

scientistAck = false; 

} 



main { 

Sensor sensor® (admin) : (sensor®period) ; 
Sensor sensor 1 (admin) : (sensor lperiod) ; 
Scientist scienti st (admin) :() ; 
Rescue rescue (admin) :() ; 

Admin admin ( sensor® , sensor 1, scientist, rescue) :() ; 



Listing 5: A Timed Rebeca model of the sensor network example 



